When data is communicated between a base station of a wireless communication network and a User Equipment (UE) served by the base station, a Radio Link Control (RLC) protocol can be applied as an RLC layer being a sub-layer of Layer 2 for handling this data communication, which has been specified by the Third Generation Partnership Project (3GPP) for Long Term Evolution (LTE) networks. The RLC layer is typically implemented by using data receiving and transmitting RLC entities in both the base station and the UE. The RLC entities are configured to exchange data in the form of Service Data Units (SDUs), of a higher layer over a logical channel configured by the so-called Radio Resource Control (RRC) layer thus being a higher layer above the RLC layer. On a lower layer called the Medium Access Control (MAC) layer, such logical channels are mapped to transport channels where the data is communicated in the form of data blocks, which communication is controlled by a so-called MAC-scheduler.
At RLC level, data in an SDU may further be re-arranged and segmented into different chunks of data, referred to as Protocol data Units (PDUs), before transmission, which are put together again at the receiving side. A PDU may be either smaller or larger than the SDU such that an SDU may be divided into several smaller PDUs, or data in multiple SDUs may be concatenated into fewer PDUs. Depending on the communication service used and/or current traffic situation, it may be required that reception of the transmitted PDUs is confirmed by means of PDU status reports sent from the data receiving RLC entity in one node as feedback to the data transmitting RLC entity in an opposite node. This can be applied for both downlink and uplink communication of data.
The RLC entities can be configured to apply different communication modes referred to as Transparent Mode (TM), Unacknowledged Mode (UM) and Acknowledged Mode (AM). In AM, PDUs are communicated and acknowledgement of correct reception of the PDUs is required and expected at the data receiving RLC entity in the form of the above-described PDU status reports, which is a process commonly referred to as Automatic Repeat request (ARQ). TM and UM do not require any such status reporting and any data that has not been received properly will be missing or discarded at the receiving side and no retransmission of the missing data will be requested either. Which mode to use for a session is decided by a radio bearer mapping function at the base station, typically based on the type of service used and possibly also on the available resources, and the selected mode is signalled from the base station to the UE at establishment of a radio bearer, referred to as “radio bearer setup”.
In the following description, RLC and AM will be used as an illustrative example, although the issues and features discussed in this disclosure may apply to any mechanisms involving status reporting of correctly received and decoded data regardless of whether the data is received in PDUs or any other format.
In FIG. 1, a base station 100 is schematically shown comprising a data receiving RLC entity 100a and a data transmitting RLC entity 100b. Further, a UE 102 served by base station 100 comprises a data receiving RLC entity 102b which can receive data, e.g. PDUs, from the data transmitting RLC entity 100b, and a data transmitting RLC entity 102a which can transmit data, e.g. PDUs, to the data receiving RLC entity 100a. 
With this configuration, data in the form of PDUs may be sent on an uplink channel from the data transmitting RLC entity 102a to the data receiving RLC entity 100a. In that case, corresponding PDU status reports may be sent as feedback on an opposite downlink channel from the data receiving RLC entity 100a to the data transmitting RLC entity 102a, such as when the above AM is used, as shown in the figure. Correspondingly, PDUs may also be sent on a downlink channel from the data transmitting RLC entity 100b to the data receiving RLC entity 102b. In that case, PDU status reports may be sent on an opposite uplink channel from the data receiving RLC entity 102b to the data transmitting RLC entity 100b. 
There are some drawbacks associated with the use of status reporting, e.g. according to the above AM RLC procedure, such as delayed data delivery, increased signaling overhead and pointless or unnecessary re-transmissions. For example, required and expected status reports may sometimes not arrive on time or not at all to the data transmitting node, resulting in re-transmission of data since that data has not been acknowledged by the data receiving node, at least as perceived by the data transmitting node. This situation may thus occur even when the data has in fact been received and decoded successfully at the data receiving node and an acknowledging status report has been sent but not delivered properly or in due time to the data transmitting node, for some reason.
In some cases, a polling procedure is applied where the data transmitting node explicitly commands the data receiving node to send a status report as feedback indicating whether transmitted data has been properly received, by adding a poll to the data transmitted to the data receiving node. A poll may be sent by setting a bit in a header field attached to the transmitted data, e.g. a specific polling field in the header is typically set to “1”. Such polls are sent according to a certain polling frequency and any data that has not been acknowledged by the data receiver before expiry of a timer will become a candidate for retransmission.